
Europaisches Patentamt 
European Pat nt Offic 
Office u rope en des brevets 





@ Publication number : 0 667 577 A1 



EUROPEAN PATENT APPLICATION 



(21) Application number : 95200343.2 

(22) Date of filing : 13.02.95 



© int. ci. 6 : G06F 12/00, G06F 1/00 



(So) Priority : 11.02.94 NL 9400222 



(53) Date of publication of application ; 
16.08.95 Bulletin 95/33 



(G) Designated Contracting States : 

AT BE CH DE DK ES FR GB GR IE IT U LU MC 
NL PT SE 



@ Applicant : Westra, Seerp 
53, Kapteynlaan 53 
NL-3571 XL Utrecht (NL) 



(72) Inventor : Westra, Seerp 
53, Kapteynlaan 53 
NL-3571 XL Utrecht (NL) 

(74) Representative : Merkelbach, B. 
Van Ruysdaellaan 47 
NL-2264 TK Leidschendam (NL) 



(54) Procedure for data file authentication. 



(57) Proposed is a procedure for the subsequent 
demonstrable initial electronic storage, particu- 
larly of a digitizable document insensitive to 
computer fraud, such as a computer file 
established on a given date. The object is to 
lend legal probative value to such electronically 
established and stored documents, by compari- 
son to the original. As a result, unauthorized 
changes made later are detected immediately. 
This is achieved/calculated by means of a com- 
puter program which in accordance with a par- 
ticular mathematical algorithm records a 
unique number for a document, by means of an 
unchanging so-called check sum, i.e. the Mes- 
sage Authentication Code. 
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The invention involves a procedure for subse- 
quently demonstrable initial electronic storage, par- 
ticularly of a digitizable document insensitive to com- 
puter fraud, such as a computer file established on a 
given date. 5 

The object of the invention is to lend probative 
value to electronically stored documents, such as 
computer files, whenever needed. This is done by 
means of so-called authentication of data files. In its 
simplest form, this is intended to demonstrate in a le- 10 
gaily reliable way, at a later stage, that a particular 
document which has been established on a given date 
(e.g. an agreement), when reproduced for some rea- 
son, has remained unchanged even after a certain 
period of time has lapsed. Specifically, this can be 15 
used in a verification procedure to check that no 
changes whatsoever have been made. 

To that end a computer program calculates, in ac- 
cordance with a particular mathematical algorithm, 
two unique numbers of a document, e.g. a computer 20 
file, viz. the so-called check sums or Message Au- 
thentication Codes, hereafter to be referred to as 
MACs. If said computer file remains absolutely un- 
changed, a repetition of that calculation with the same 
program will once again produce exactly the same 25 
MACs. And, conversely, the slightest change in the 
document will always result in different MAC num- 
bers. By 'anchoring', so to speak, the two MAC values 
in time, e.g. by publishing the MAC in a daily news- 
paper of which copies are available for public perusal, 30 
a dual checking option is obtained. Preferably, this 
anchoring in time should be effected through a reli- 
able third party. 

Up to now there has not been any real need yet 
for the highest degree of certainty in authentication of 35 
data files. However, in the computer age, and also on 
account of the ever present old-fashioned mediums of 
proof which are becoming increasingly sensitive to 
fraud, it has become necessary to apply to that high- 
est degree of certainty to the aforementioned method 40 
of authentication of data files as well. 

According to the invention, this is achieved by 
enabling the user to prove beyond doubt that since 
the time of the initial storage said document has re- 
mained entirely unchanged in every respect. To that 45 
end such document is stored after being attributed 
two unique codes (MACs), which code is derived from 
or calculated with, respectively, a first computer pro- 
gram calculating two unique codes according to a 
particular mathematical algorithm. The result, prefer- 50 
ably in the form of e.g. an authentication file name, is 
subsequently recorded and/or registered in a public- 
ation medium, in particular a dated Gazette or similar 
reliable medium of verification, accessible to anyone, 
this being the so-called data file authentication of the 55 
document. A second virtually identical computer pro- 
gram serves as a checking program; it operates by 
the same calculation method, using a key which is 



identical for both programs. This program can, prefer- 
ably, be made available to someone who, for reasons 
of his own, wishes to perform a first objective check 
on the presence of the allegedly unchanged version 
of the authenticated document on the initial storage 
date, all this in such a way that for a subsequent legal 
and conclusive verification regarding the original time 
of existence of the authenticity in relation to this docu- 
ment, no assistance whatsoever is needed from the 
person(s) who once executed the basis of the data file 
authentication, while it is not possible, when recalcu- 
lating for that purpose, to subsequently influence the 
programmatic set-up for that data file authentication 
in any respect and/or at any later time. 

According to the invention this set-up can be ach- 
ieved because the first computer program also per- 
forms a calculation for each user or licencee by 
means of the exclusive hardcoded secret key as- 
signed to each user, which can be made visible on the 
user screen at any time, by means of which the sec- 
ond (checking) program can reproduce the second 
unique code published earlier, in order to prove the 
authenticity of said (checking) program. 

Another result of the procedure as provided for by 
the invention is that the user is no longer dependent 
on e.g the records of an authenticator such as a no- 
tary public, a registration inspector or the like to be 
able to carry out the necessary reliable checking of 
time and original unchanged contents of a document, 
but instead he can independently and objectively 
reach the required conclusion with respect to the au- 
thentication of data files. This is achieved by making 
the second computer program available to anyone re- 
questing same for the purpose of a possible later 
checking of time and contents of the document, e.g. 
on the basis of depositing same with a notary public. 

By following the procedure as advocated by the 
invention it has now become possible to even supply 
electronically stored files adapted in this way, whil 
fully meeting the check which is essential to that end. 
In particular this may play a part with bank transac- 
tions in which the proof of an implementation date 
is/becomes critical. 

The invention enables the user to avoid and/or 
subsequently detect any sensitivity to fraud if the first 
and second computer programs are fully identical, so 
that also the hardcoded secret key of the first comput- 
er program is integrated into the second computer 
program. 

Below the invention will be explained further, by 
means of the instructions for use, in which the new 
procedure will be referred to as CertiFile® (® regis- 
tered trad mark). 
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TECHNICAL AND LEGAL ASPECTS IN DETAIL 
Authentication fdatafil s 

Increasingly, documents are only stored elec- 
tronically and exchanged in the form of computer 
files. Since any computer file can be changed at will, 
this can hardly serve as a piece of evidence. 

CertiFile, however, offers you a program and a 
method which do lend probative value to a computer 
file: authentication of data files. 

Method of operation 

The CertiFile program locks a computer file by 
calculating two so-called check sums. These are 
unique numbers, resulting from a particular series of 
mathematical calculations. They enable the user to 
check whether or not a file has remained absolutely 
identical since a previous calculation. If the slightest 
change has been made to that file, then a recalcula- 
tion will never produce the same check sums. There- 
fore the authenticity of a locked file can be deter- 
mined later, on the basis of the two check sums. The 
CertiFile program carries out the calculations in ac- 
cordance with the algorithms of ISO standard 8731- 
2, as also used in payment transactions (International 
Standard ISO 8731-2, second edition 1992-09-15: 
Banking - Approved algorithms for message authen- 
tication - Part 2: Message authenticator algorithm.). 

TNO, the Dutch Organization for Applied Scien- 
tific Research, has tested and confirmed the correct 
implementation of this ISO standard in the CertiFile 
program. 

Two check sums based on two keys 

The two check sums always consist of 8 charac- 
ters, e.g 28A4D5E6 and E267F9A1. The first check 
sum (public check sum) is calculated by means of the 
so-called public key, which is the same for every pro- 
gram supplied. The second check sum (private check 
sum) is calculated by means of the so-called private 
key, which differs for each licencee. i.e. for each pro- 
gram supplied. 

The public check sum 

When locking, the program makes an exact copy 
of the adapted file, the so-called retention copy. This 
retention copy receives a new file name, the first 8 
characters of which consist of the public check sum. 
For instance, the copy of file CONTRACT.DLK may 
get file name 28A4D5E6.000. Thus the public check 
sum can always be deduced from the file name of the 
retention copy. This makes subsequent checking 
very simple (further details under Checking Pro- 
gram). 



The private check sum 

The private check sum is an extra. It serves to 
rule out fraud with the Checking Program in case of 
5 a verification procedure. 

Recording of the check sums 

For a subsequent verification the public check 
10 sum (incorporated into the backup copy file name) 
and the private check sum must be unchangeably re- 
corded in time. Sometimes a mutually dated and sign- 
ed statement may suffice to that end, e.g. in those 
cases in which the opponent is already known, such 
15 as in an exchange of computer files. However, if a 
possible opponent is not yet known, CertiFile B.V. 
may be called in for a valid time stamp: publication in 
a Gazette. 

20 Time stamp: Gazette 

The user informs CertiFile of the backup copy file 
name and the private check sum. (The program auto- 
matically includes these in a Report Message to be 
25 faxed to CertiFile, see p. 5). Hour and minute of re- 
ceipt are noted. CertiFile puts these data into the 
Gazette of that or the next day. 

Authentication of data files after 20 September 
10.00 hrs. 

30 001-10.44 | 1AC71B2A.O0O I 27D8D23E 

002- 14.06 | 28A6443E.000 I A34D7A24 

003- 15.22 I 5D4A34A2.000 I 3E34A98D 

004- 16.45 | 5AD53A1A.000 I 13E59821 

etc. 

35 With this the circle is round: the contents of th 

file are frozen in the check sums and these, togeth r 
with the time of the report, are frozen in time by being 
published in the Gazette. 

In confirmation thereof the user receives a pho- 

40 tocopy of the Gazette publication. 

Verification 

In order to demonstrate that a file has not been 
45 changed since a particular date, the user only needs 
to show on a Personal Computer that the check sums 
the CertiFile program produces for that file are iden- 
tical to the ones mentioned in the Gazette. However, 
an opponent could dispute the authenticity of the Cer- 
50 tiFile program used. That is where the checking pro- 
gram CHECK.EXE comes in. 

Checking program CHECK.EXE 

55 This program, which may be distributed freely, is 

located on the program disk in directory \ check. The 
instructions for use, as included below, are also locat- 
ed there in the form of a read.me file, intended for re- 
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cipients of the checking program. 

CHECK.EXE serves two purposes: 

- checking by recipients of authenticated files 

- verification 

The program uses the same calculation method 5 
and the same public key as the CertiFile program. 

Operation of CHECK. EXE 

Upon entering command CHECK the program 10 
displays the parameters that may be used (both upper 
case and lower case are permitted): 
CHECK <[path] file name> [<private key>] 

Items in square brackets are optional. After 
CHECK and a space the following may be entered: 15 

1. the backup copy file name, possibly preceded 
by the path 

2. idem, space, private key 

The private key, which is diffe/ent for each licen- 
cee, may be displayed on the screen with the Certi- 20 
File program, by using <set-up>. This key consists of 
2 times 10 characters, separated by a space, e.g. 
0X2A5E249B 0XA5D473B5. 

CHECK. EXE examples 25 

The following are some examples of control com- 
mands, followed by the result CHECK.EXE displays 
on the screen: 

CHECK A:\6AB45628.000 30 

Public check sum matches file name! 

or 

No match! 

So it appears that either nothing or something 
has been changed in the authenticated file. 35 
CHECK A:\6AB45628.00 0X2A5E249B 

0XA5D473B5 

Private check sum with key 
0X2A5E249B 0XA5D473B5 is 3D5674B1 

If nothing has been changed in the authenticated 40 
file, the private check sum recalculated now will be 
identical to that of the original locking (as stored in the 
log file and published in the Gazette. 

If, however, something has been changed, then 
the private check sum calculated will not be the same. 45 

Protection against fraud 

The CertiFile method offers four ways of protec- 
tion against possible fraud with the CertiFile checking so 
program by a licencee: 

1. Addition of the private key to the CHECK.EXE 
command line. 

2. Initial authentication by CertiFile of the check- 
ing program identical for every user, and public- 55 
ation thereof in the Gazette. 

3. Inital locking by CertiFile of each CertiFile pro- 
gram supplied (CERTI.EXE) and publication 



thereof in the Gazette. 

4. Depositing copies of the checking program 
with a notary public. 

In extreme cas s it is possible for a recipi nt of a 
locked file to make a deceptively genuine looking 
CHECK.EXE which puts the desired message on the 
screen. 

The first way to counteract this is for the licencee 
to request that his private key be added to the com- 
mand line. This is only effective if the fraudulent party 
did not know his private key before. In case he did 
(e.g. if he became acquainted with it during a previ- 
ous, similar verification procedure, and incorporated 
it into the imitation CHECK.EXE), the licencee can 
lock the imitation CHECK.EXE with his CertiFile pro- 
gram, and demonstrate that the resulting public 
check sum differs from the one CertiFile initially pub- 
lished in the Gazette and printed on all packings and 
the like. 

If thereupon the opponent should dispute the au- 
thenticity of the CertiFile program used, then the li- 
cencee may use that program to authenticate his own 
CERTI.EXE: the backup copy file name will be iden- 
tical to the one CertiFile published in the Gazette af- 
ter the program was supplied. 

A fourth option to counteract presumed manipu- 
lations with the checking program is depositing with 
a notary public. This notary public holds original cop- 
ies of the checking program and will make a copy 
available to contending parties at any licencee's r - 
quest. 

The four options to rule out fraud in verification 
procedures, as described above, can be regarded as 
adequate. 

Legal procedure 

In principle, as is well-known, evidence in a legal 
procedure may be furnished by every means. The 
judge assesses the value of the evidence. The 
strength of the CertiFile data file authentication pro- 
cedure is the increased authenticity: the judge will 
now be able to attach more weight to the value of this 
medium of evidence, as he will be more convinced 
that the evidence cannot have been tampered with. 

Therefore the CertiFile procedure considerably 
increases the chances of a successful furnishing of 
proof. 



Claims 

1. Procedure for subsequently demonstrable initial 
electronic storage, particularly of a digitizable 
document insensitive to computer fraud and 
other so-called hacker manipulations, such as a 
computer file established on a given date, with 
the object of subsequently being able to show be- 
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yond legal doubt that said document has re- 
mained unchanged in every respect since the 
time of the initial storage, which storage to that 
end is effected by means of attributing a unique 
code (MAC) to such document to be stored, which 5 
code is derived from a first computer program 
that calculates two different unique codes in ac- 
cordance with a particular mathematical algo- 
rithm, which results are thereupon, preferably in 
the form of e.g. a file name, recorded and/or reg- 10 
istered in a publication medium, in particular a 
dated Gazette or similar reliable medium of veri- 
fication, accessible to anyone, this being the so- 
called authentication of data files of the docu- 
ment whereby a second virtually identical com- 15 
puter program serves as a checking program and 
which operates by the same calculation method, 
using a hard coded key which is identical for both 
programs which program can, preferably, be 
made available to someone who, for reasons of 20 
his own, wishes to perform a first objective check 
on the presence of the allegedly unchanged ver- 
sion of the authenticated document on the initial 
storage date, all this in such a way that for a sub- 
sequent legal and conclusive verification regard- 25 
ing the original time of existence of the authenti- 
city in relation to this document, no assistance 
whatsoever is needed from the person(s) who 
once executed the basis of the data file authen- 
tication, while it is not possible, when recalculat- 30 
ing for that purpose, to subsequently influence 
the programmatic set-up for that data file authen- 
tication in any respect and/or at any later time. 

Procedure according to claim 1, characterised in 35 
that for each user (licencee) the first computer 
program also carries out a calculation by means 
of the exclusive so-called private hardcoded se- 
cret key assigned to each user, which can be 
made visible on the user screen at all times, by 40 
means of which the second checking program 
can reproduce the second unique key published 
earlier, in order to prove the authenticity of said 
checking program. 

45 

Procedure according to claim 2, characterised in 
that the second computer program, for possible 
later checking of time and contents of the docu- 
ment, is made available to anyone upon request, 
e.g. on the basis of depositing same with a notary so 
public. 

Procedure for the demonstrable authentic supply 
of electronically stored files or parts thereof, 
which are stored in accordance with the proce- 55 
dures outlined in any one of the foregoing claims. 
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